1. Field of the Invention
The present invention relates to user interfaces having multiple windows and displaying server-provided data in a client/server system.
2. Description of the Related Art
The number of people using computer systems in their daily lives has increased dramatically with the growth of the Internet and the World Wide Web, which provide access to virtually unlimited information stored by computer systems all over the world. As the sophistication of computer users increases, user expectations of the types of user interfaces and functionality that should be provided by software applications also increase.
Many software development environments for desktop and network applications enable a developer to assemble an application using two or more components that provide different types of functionality to the application. Components provide the capability for an application to provide rich, fully-featured user interfaces, including functionality for windows, buttons, scrollbars, and so on. A component can be re-used by many applications within a computer or among computers in a network. The application provides an environment, also referred to as a context, in which the component runs. Examples of applications built from components are word processors, such as Microsoft Word, and database programs, such as Microsoft Access.
A component can include display code and functional code, where the display code can display a visual portion of a user interface and the functional code controls when the visual portion is displayed and other functions, such as responding to a user action taken with reference to the visual portion. For example, a component's display code can display a button in a user interface, and the component's functional code can determine when the button is to be displayed and specify a function to perform when a user performs an action with reference to the button. For example, the user can point a cursor to the button (using a mouse or other pointing device) and click on the button, which causes the functional code for responding to activation of the button to be performed. A component is not, however, required to include display code or to display a visual portion of the user interface. When a component does not display a visual portion of the user interface, the component is sometimes referred to as being invisible.
Unfortunately, the functionality to implement components is not easily achieved using the technology used for the web. Web browsers provide information in the form of a web page, which is produced by interpreting a text document encoded using a language specially developed for web applications, Hypertext Markup Language (HTML). A single HTML document cannot easily provide all of the information needed to provide a sophisticated user interface in the form of a web page. Because of the limitations of HTML, web application developers face significant challenges in providing user interfaces that can access the wealth of information available via the Internet using web technology and yet provide the sophisticated features meeting users' expectations.
For example, a common format for user interfaces is to display descriptions of content items available in a multi-window format, with different types of content items grouped into different windows. Such a multi-window format enables a user to view many types of content simultaneously. Typically, a main window, also referred to as a primary window, serves as the user's primary interface to interact with an application displaying the data. A given window, such as the main window, can open other windows, also referred to as secondary windows, to provide the user with the capability to interact with particular types of application-specific data.
When an application needs input from a user, the application provides a window into which the user enters or provides the information. For example, a typical Open menu item requires the name of a file to open, and the application provides a secondary window into which the user can type the name of the file. Secondary windows to receive information from a user can be implemented using many types of components; for example, a dialog box component is often used to open a new window in response to input from the user (here, clicking on the Open menu item). In the dialog box, the user types the name of the file. Another example of a component that opens a new window to receive information from a user is a listbox component, which can provide a list of existing files from which to choose and the ability to create a new file. Similarly, a tree component provides a list of folders from which an existing file can be selected and/or a new file or folder named. Another example of a component that opens a new window to receive additional information from a user is a checkbox component. A checkbox component provides a labeled box with a list of pre-determined options, wherein each option can be checked or unchecked to select or clear that option.
The application typically creates a user input box, such as a dialog box, when the user clicks the menu item. The application typically destroys the dialog box immediately after the user supplies the information or closes the dialog box. For example, the user can close the dialog box by clicking on an OK button to accept the data shown, entering new data and clicking on the OK button, clicking on a cancel button to close the window without entering new data, or clicking on a close window button.
Many applications also use dialog boxes to display information or options while the user works in another window. For example, word processing applications often use a dialog box that provides a text search option. While the application searches for the text, the dialog box remains on the screen. The user can then return to the dialog box and search for the same word again, or the user can change the entry in the dialog box and search for a new word. Typically, the application creates the dialog box when the user clicks the menu item and continues to display the dialog for as long as the application runs or until the user explicitly closes the dialog box.
Some types of display windows do not typically receive input from the user. For example, HTML provides the ability to display a tool tip, which is a small context window that includes descriptive text displayed when the user moves the pointer over the context window. Unlike a link, the tool tip is activated when the user points to the context window containing the descriptive text. The descriptive text within the context window is normally distinguished from other plain text in the user interface to indicate to the user that the descriptive text within is actionable. For example, the descriptive text may have a visible context window border or be underlined to visually distinguish the descriptive text from other plain text. However, while tool tips can display data related to the actionable user interface object, tool tips are typically used as a help utility to display a fixed text informing the user of the functionality provided by an actionable user interface object. Typically, tool tips are not persistent, such that the tool tip appears when a pointer to the descriptive text hovers for a short period of time, and the tool tip disappears after another short period of time. Furthermore, tool tips typically do not provide a mechanism for the user to provide input or otherwise interact with the tool tip to obtain additional information about the data displayed within the context window.
Some windows allow the user to view information and return to the previous task without closing the window or providing input. Such a window is referred to as a modeless window. In contrast, a window that requires the user to either supply additional information or explicitly close the window is referred to as a modal window. Applications use modal windows, for example, in conjunction with menu items that require additional information before proceeding. The user cannot switch back to the host window that opened the modal window until the modal window is closed. In other words, the modal window retains input focus and receives user input from the keyboard or mouse until the modal window is closed. Modal windows are simpler to manage than modeless windows because they are created, perform their task, and are destroyed by calling one or more functions in the display code for the window. However, modal windows do not allow a user to switch tasks at will.
A sidebar window typically is a narrow window providing a limited number of selection options and/or a limited amount of data. Because a sidebar window and its contents are often referred to collectively as a sidebar, the term sidebar is used herein to describe both the sidebar window and the contents of the sidebar window. The sidebar window is typically presented in conjunction with a larger display window that has space to display more data about a particular selection in the sidebar window. For example, sidebars may provide information such as news headlines or other content item descriptions, where the content item itself is available by clicking a hyperlink, also referred to herein as a link, associated with the content item description. When the link is activated, the content item itself is typically displayed in a new window, thereby overlaying both the larger display window and the sidebar window.
The sidebar window and the larger display window can be siblings opened by a common parent window or in a parent/child relationship to one another. Either the sidebar window or the display window can serve as a host of the other. For purposes of discussion of sidebar windows in this document, the term sidebar window is not limited to a window being presented on the left hand side of the larger display window. The term sidebar window or sidebar is also used to refer to a window having a limited area for displaying data, whether the window is displayed on the left hand side, right hand side, top, or bottom of the larger display window.
The web operates under a request/response model for a client/server environment, with the web client requesting a web page and the web server providing the web page in response to the request. A web server does not independently send web pages to the web client without first receiving a request for the data from the web client. Furthermore, the web client and web server are connected only for the amount of time it takes to send a response to the request, or, in a limited number of implementations, for a short period of time after receiving the response to determine whether additional data are needed immediately. Such a brief connection after the response is received is sometimes referred to as a keep-alive connection, but most busy web servers do not provide keep-alive connections. Typically, no persistent connection is provided between a web server and web client when a request for a web page is not pending, thus limiting the web server's ability to communicate information to the web client. The web client's ability to operate on server-provided data without sending a request to a server is limited because the data are provided within an HTML document. Sending a request whenever additional data are needed expends resources and adds to congestion over the network between the client and server.
When data are displayed within the same user interface but in different windows simultaneously, most applications try to ensure that the data are consistent to avoid user confusion. Providing data consistency between user interfaces implemented using web browsers poses several challenges. For example, each web page provided by a web browser within a single user interface is typically provided by a different web browser instance that is independent of the other web browser instances. When the web page allows the user to change data, the web browser instance receiving the change to the data displayed by the web page sends a request to a web server to make the change. The web server changes the data and sends a response to the web browser instance that requested to make the change, where the response indicates that the change has been made. Because web browser instances must send a request to the server to receive updated data, to ensure consistent simultaneous data presentation, either web browser instance must continuously send requests to determine whether the data that it is capable of displaying has changed. This solution is described as polling, but polling greatly adds to the number of request to which the web server must respond, potentially overwhelming the web server. Another solution is to provide a persistent connection to the web server, but then only a limit number of web browser instances can be supported by each web server.
In an environment such as the web, users have become accustomed to viewing multiple web pages showing diverse content displayed simultaneously. Users can freely move from one page to another, opening two windows simultaneously to display web pages, drilling down from one web page to another, and so on. Popup windows are annoying to users because they interrupt the flow of the user's task activity, especially when the user did not intentionally request the display of the popup window.
What is needed is a solution that combines the flexibility of user interfaces implemented using components with the wealth of content available and viewing flexibility of a web application in a single user interface. Preferably, the solution would enable a user to view additional information in a specialized window similar to a popup window that appears upon request, allows the user to close the specialized window easily, and preserves the ability to view the original content, related content, and web pages simultaneously.